Upgrade Helm Release
How to override Helm chart's default values and how to upgrade a version of a Helm release.
The Metrics Server for Kubernetes Dashboard#
If we take a closer look into our Kubernetes Dashboard, especially on the page with listed Pods, we might see that something is missing. To be specific, there are no illustrative curve charts that represent how much CPU and memory are consumed by applications, as givenbelow:
In this lesson, we’ll address this problem and tune our Helm release to show it.
To enable it we need to have the Kubernetes Metrics Server installed in our cluster. This is an application that collects information about resource usage (such as CPU and memory) from the cluster and exposes it using an API. Then an API is consumed by the Dashboard.
Enable the Metrics Server#
There are a couple of ways of deploying the Metrics Server into the cluster. It could be already provided by a public cloud provider or it could be installed with Helm using a separate Helm chart. Luckily for us, we don’t need to use a separate Helm chart. The Metrics Server is already embedded in our Helm chart. We just need to enable it. To learn how to do that, we need to have a look into the values.yaml file and find a part that is responsible for that, as shown below:
Here, two main properties are responsible for enabling Metrics Servers—metricsScraper and metrics-server. By default, both of them are disabled.
Also, please note how descriptive and informative the comments here are. It’s a good practice to put them into a values.yaml file to help the users of a chart figure out what the purpose of each property is. (This advice will come in handy when we start to create our chart.)
Apart from enabling both metricsScraper and metrics-server, we need to add two arguments to the server startup command to skip security protection (since we’re developing everything locally).
With that, we’re ready to apply it to our cluster. But there is a problem here.
The helm install command can be used only when we install a Helm release for the first time. If we want to adjust an already existing one we need to use helm upgrade.
Helm upgrade#
It works very similarly to the helm install command. We can check their definitions (using the --help flag) and see for ourselves that they have a lot in common. Later in this lesson, we’ll explain what the differences between these two are.
Now, let’s upgrade our Helm release:
To verify the number of Pods you can run the kubectl get pods -n monitoring command.
- Set up kubectl proxy as follows:
kubectl proxy --address 0.0.0.0 --accept-hosts='.*'
-
Open a new terminal
-
Create a ClusterRoleBinding
kubectl -n monitoring create clusterrolebinding dashboard-kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=monitoring:dashboard-kubernetes-dashboard
- List the
secrets, as shown below:
kubectl get secrets -n monitoring
- Get the token, as follows:
kubectl describe secret -n monitoring dashboard-kubernetes-dashboard-token-<INDIVIDUALT-SUFFIX>
- Then, open the URL provided at the bottom of code sandbox:
/
First, let’s look at the parameters that were provided into the command:
helm upgrade: This is the basic command for upgrading an already existing Helm release.[NAME]: This is the name of the Helm release for which change will be applied; here, it isdashboard.[CHART]: This is the name of the Helm chart for which change will be applied; here it iskubernetes-dashboard/kubernetes-dashboard.
Apart from the mandatory arguments, two other parameters were provided, as follows:
-n monitoring: This is the Kubernetes namespace name where the upgraded Helm release is located.
We can also find two other arguments which are not mandatory, but they make sure that a release will be installed in the interactive widget. These are as follows:
--install: This makes sure that if a release isn’t installed yet, it will be.--create-namespace: This creates a Kubernates namespace if it doesn’t exist.
Validate the Helm release after an update#
Check the Dashboard page#
First, let’s test to see if Metrics are enabled in our Dashboard. To do that, open it in a browser (the hint above the interactive playground will help refresh your memory).
If we go now to the Pods page or the specific Pod view, we can see illustrative charts, as shown below.
Review the history of the releases #
Now, let’s examine our release with Helm CLI. First, let’s see what has changed in the helm list:
The output will be as follows:
NAME REVISION UPDATED STATUS APP VERSION
dashboard 2 2021-12-01 deployed 2.4.0
Our dashboard Helm release has been bumped up to revision 2.
If we want to check all the revisions we can use a very handy command, helm history:
The output will be as follows:
REVISION UPDATED STATUS CHART
1 Dec 1 2021 superseded kubernetes-dashboard-5.0.4 Install complete
2 Dec 1 2021 deployed kubernetes-dashboard-5.0.4 Upgrade complete
From the above output, we can see that the 1 revision is now outdated (superseded) and the latest version, 2, has been deployed.
Check the overridden values#
Moreover, we can check what values have been applied to this specific release using the already mentioned helm get command:
The output will be as follows:
USER-SUPPLIED VALUES:
metrics-server:
args:
- --kubelet-preferred-address-types=InternalIP
- --kubelet-insecure-tls
enabled: true
metricsScraper:
enabled: true
This time, however, we don’t use helm get all but the helm get values command which prints only those values that have been provided by us. We can use this command to debug our Helm release, which can be very useful in complex systems.
Setting Values during Installation
Install Helm Release with Multiple Values Files